1. Field of the Invention
The present invention relates to the improvement of the management of the messaging features of a communication device cooperating with of a portable device.
2. Description of the Related Art
A communication device is an electronic device able to communicate over a network (be it wired or wireless). GSM, UMTS, WiFi, IrDA, Bluetooth, FireWire, USB, Ethernet or PLC (power line communication) are non-limitative examples of networking technologies that can be used by the communication device in order to communicate.
The communication device can be a mobile phone, a Personal Digital Assistant (a.k.a PDA), a smart phone (i.e. a mobile phone with PDA capability), a laptop or desktop computer, an Internet kiosk, etc. The communication device comprises at least one messaging user interface, at least one web browser, and possibly one or more messaging clients.
A user interface is defined as an aggregate of means comprising hardware means (e.g. keyboard, mouse, joystick, screen, microphone, loudspeaker, etc.) by which the users (in particular human beings) interact with a particular machine (the communication device). A user interface may also comprise software means defining a particular manner of using the hardware means of the user interface, for example such software means may consist of a GUI (graphical user interface) defining the elements which have to be displayed on a screen (buttons, text boxes, icons etc.). When possible, such software means are made independent of the hardware means (e.g. an HTML page is normally displayed in the same manner on the cathode-ray tube screen of an IBM PC desktop computer or on the liquid crystal display of a Macintosh laptop). A messaging user interface is defined as a user interface usable for accessing messages, including complex messages, in a user-friendly manner. Complex messages are messages with high entropy. The concept of entropy is well known in information theory. In simplified terms, the entropy of a message is the average number of bits needed to encode the message optimally. In the context of the invention, an entropy is high if it is greater than 100. A user-friendly manner is defined as a manner such that the user can access at least a high entropy subset of a message at the same time. A high entropy subset of a message is defined as a subset of a message, the subset having a high entropy (more than 100). The notion of same time is defined with respect to a human being's senses, which can hardly distinguish the order of events occurring within a very short period of time such as one tenth of a second. Therefore any time within a time interval of one tenth of a second is considered to be the same time. Accessing a message is defined as providing the user with the knowledge of the contents of the message, and may also encompass manipulating the message (e.g. editing, moving, deleting, etc.). A message is any information, thought or idea expressed in a plain or secret language, prepared in a form suitable for transmission by communication means. In general messages involve a human being in the sense that they target human beings and/or are generated by human beings. Different types of messages are used in state-of-the-art systems (text messages, messages consisting of sounds, images, movies, etc.). Let's consider text messages containing 100 printable ASCII characters (there are 95 possible printable ASCII characters). The entropy of such messages is Log2(95100)=657, which is more than 100. Consequently, a 100-character wide one line display (or a ten lines by ten columns display) usable for displaying any possible 100 printable ASCII characters message is an example of messaging user interface. Let's consider a headset used for a voice communication encoded at an average 8 kbit/s (low quality used in particular for cellular phones). During one tenth of a second, around 800 bits are transmitted (which is more than 100), therefore this headset used in this application is another example of a messaging user interface. A second series of examples is given below for user interfaces which are not considered messaging user interfaces. An LED (light emitting diode) installed on a communication device can be used to indicate whether there is some communication going on or not. Although the same LED could be used to send elaborate messages (e.g. in Morse code), what matters here is the actual application in which the LED is used and the amount of information (i.e. message complexity) that can be communicated to the user at a given point in time, i.e. LED ON or LED OFF (two possible “messages”). Either the LED is on and there is some communication going on (LED ON) or it is off indicating that there is no communication (LED OFF). The entropy is Log2(2)=1, which is below 100. Similarly, a piezoelectric diaphragm can be used to produce a beep or series of beeps informing the user of a failure of the communication device, such as a personal computer motherboard, and the number and duration of beeps provides some diagnostic information. Here again, what matters is that at a certain point in time there is a beep or there is no beep, therefore only two subsets of messages are possible (although the succession of beeps forming the overall message may have a more elaborate meaning). It should be noted that the aforementioned headset used in the application described for the piezoelectric diagram (simple diagnostic beeps) is not a messaging user interface. Indeed, although the headset would potentially have the capability to communicate a complex message in a different application, it doesn't communicate complex messages in the application considered in this context. Yet another example of user interface not considered a messaging user interface is an LCD (Liquid Crystal Display) used solely to display any six decimal digit number, as is the case on certain One Time Password tokens. The entropy of such a message is Log2(106)=20, which is below 100. Although the same LCD might have the capability to display complex messages in a different application, the One Time Password token of the example doesn't take advantage of such possibility. Therefore an LED, an LCD or a piezoelectric diaphragm used in the applications cited in the above second series of examples does not constitute a messaging user interface in the sense of the present invention. Any user interface that is designed to convey only a limited set of messages (according to the objective criterion stated above), such as short predefined messages, is not considered a messaging user interface in the context of the invention. Practical examples of complex messages include email messages (electronic mail messages), IMS messages (Instant Messaging Service messages), SMS messages (Short Message Service messages), MMS messages, (Multimedia Messaging Service messages) or EMS messages (Enhanced Message Service messages). Usually different messaging clients manage each type of messages. The principles underlying the management of the above types of messages are well known. Those different types of messages are explained below, based on articles from WikiPedia (a free online encyclopedia), and on websites of companies specialized in mobile communications (Symbian and Ringnow). Email is a method of composing, sending, and receiving messages over electronic communication systems. Most email systems today use the Internet, and email is one of the most popular uses of the Internet. Instant Messaging Services (IMS) differ from email in that exchanges of messages happen in real time. Most IMS offer a “presence awareness” feature, indicating whether people on one's list of contacts are currently online and available to communicate. In early instant messaging programs, each letter appeared as it was typed, and when letters were deleted to correct mistakes this was also seen in real time. This made it more like a telephone conversation than exchanging letters. In modern IMS, the other party in the conversation (i.e. exchange of messages) generally only sees each line of text only after a new line is started. Instant messaging applications may also include the ability to post an away message, the equivalent of the message on a telephone answering machine. The Short Message Service, available on GSM networks, allows text messages of up to 160 characters to be sent and received via the network operator's message centre, to and from a mobile phone, or from the Internet, using a so-called “SMS gateway”. If the phone is powered off or out of range, messages are stored and are delivered as soon as possible. Multimedia Messaging System (MMS) is an evolution of the Short Message Service SMS. MMS enables subscribers to compose and send messages with one or more multimedia (digital photos, audio, video) parts. Mobile phones with built-in or attached cameras, or with built-in MP3 players are very likely to also have an MMS messaging client—a software program that interacts with the mobile subscriber to compose, address, send, receive, and view MMS messages. EMS (Enhanced Messaging Service) is an evolution of SMS, from standard 160-character text messages to multi-media messages consisting of pictures, melodies, animations and styled text. EMS allows users to create and exchange pictures, ring tones and other melodies, by downloading them from the Internet or creating custom multi-media directly on the phone. EMS is built using the existing SMS infrastructure and is a cross-industry collaboration between the handset manufacturers Ericsson, Motorola, Siemens and Alcatel, and solutions developers who provide the ability to embed simple multi-media inside SMS messages. If an EMS message is delivered to a mobile phone that does not have EMS software, the user will only see the text in the same way as an SMS. EMS remains compatible with communication devices supporting SMS only because it works with the existing infrastructure laid down for SMS, and uses the same user interfaces. EMS expands the base of applications using wireless messaging. Whereas MMS is well adapted to 3G networks, EMS is suitable for current GSM infrastructure.
A messaging client is defined as a software application providing users with means for managing their messages through a messaging user interface. Managing messages comprises receiving orders from the user and executing them (or having them executed by the relevant software or hardware component, for example by means of a function call or remote procedure call). Orders from the users comprise requests for listing messages on the messaging user interface, selecting messages, retrieving messages and communicating messages to the user through a messaging user interface. Orders from the users may also comprise requests for operations such as scrolling through messages (when messages are too big to be communicated through the messaging user interface at one time), reading, editing, writing, recording (e.g. voice or picture, for example in case of a cellular phone equipped with a digital camera), deleting, sending, receiving, forwarding, filtering, sorting, broadcasting, synchronizing or archiving messages, and others known by those skilled in the art. Orders from the users can be relayed to the messaging client through intermediate software and hardware components (located between the messaging user interface and the messaging client). For example a mouse click, resulting in an interruption sending the X and Y coordinates of the cursor, can be converted into a specific order by a module linked to a graphical user interface component, such module identifying the icon that has been clicked, for example the icon “read message”, and transmitting the order “read message” to the messaging client. Popular software comprising a messaging client include Qualcomm's Eudora, Netscape Mail, or Microsoft Outlook Express. In the field of cellular telephony, cellular phone manufacturers include a messaging client for managing messages such as SMS messages in the cellular phone. Web mail is a class of web applications that allow users to read and write e-mail using a web browser. Popular examples of web mail include Yahoo Mail and Microsoft Hotmail. In the context of web mail, the messaging client consists of the web application, which generates the web pages displayed in the web browser, and enables access to the messages.
As known by those skilled in the art, a web browser is a software application that enables a user to display and interact with documents hosted by web servers or held in a file system (in general through the HTTP protocol, although many browsers support other protocols such as FTP etc.). The web browser integrates or relies on a web protocol stack. Documents are in general in HTML or XML format, although many other formats are accepted as well (JPEG etc.). Popular browsers available for personal computers include Microsoft Internet Explorer, Mozilla Firefox, Opera, Netscape, Safari and Konqueror.
The invention relates to communication devices arranged to operate with a portable device. In the context of the invention, a portable device is defined as an electronic device with processing capability, without a messaging user interface, and which is portable (it is usually smaller than the communication device and the user of the communication device can easily carry it). Such portable device may have an LED or other basic user interface, which is not considered a messaging user interface given the definition of a messaging user interface stated above. The portable device has external communication means. The portable device is usually inserted in the communication device but could also communicate with the communication device without being inserted in it (e.g. radio communication or cable connection etc.). Portable devices can be connected to many communication devices. For example, USB smart cards have USB connectivity enabling their connection to almost any personal computer, to many PDAs, etc. USB smart card normally also have an ISO 7816 connectivity enabling their connection to bank ATMs, POS terminals, GSM cellular phones, healthcare kiosks (e.g. for the French Sesame Vitale card), and to any personal computer or device equipped with a smart card reader. The portable device is often used for authenticating the user of the communication device. In general, the portable device has no integrated power supply or battery, the portable device being electrically powered by the communication device. Examples of portable devices include smart cards (e.g. ISO 7816 smart card, USB smart card, SIM card, USIM card, MMC smart card, contact-less smart card etc.), dongles, USB keys, secureMMC devices, One Time Password tokens, memory cards etc. Portable devices may include a web server, as was demonstrated in October 1999 on a Schlumberger smart card by the university of Michigan (which published the source code of the software necessary to implement this web server), and by Bull CP8 (I-Simplify product). As known from state of the art, the term web server can have two meanings: (1) a computer that is responsible for accepting requests (in particular HTTP requests) from web browsers, and serving them web pages, which are usually HTML documents, or (2) a computer program that provides the functionality described in the first sense of the term. In the context of the invention, the term “web server” is taken in the second meaning. Portable devices may have message storage means for storing messages of a user of the portable device in the portable device.
A first problem with state-of-the-art communication devices and portable devices described above lies in the fact that it is difficult to transfer messages (“portability problem”). The portability problem is particularly significant when one wishes to transfer large numbers of archived messages. A first example of portability problem is observed while attempting to transfer all SMS messages stored in one cellular phone into a second cellular phone. For instance, when a user having a cellular phone acquires a new cellular phone, transferring all messages from the old cellular phone to the new one is complex in particular for the messages stored in the cellular phone memory. Even when the user can transfer personal data using existing communication channels between the two cellular phones (e.g. IrDA, Bluetooth or Wifi), such transfer usually requires manual intervention of the user (no automatic and generic way to do it). The user needs to spend a lot of time to transfer personal data, and not everybody knows how to do it. It should be noted that although many cellular phones use a SIM card, the SIM card being a portable device able to store SMS messages, the cellular phone sometimes stores messages internally rather than in the SIM card, because the cellular phone quite often has a bigger memory capacity than regular SIM cards (however certain types of SIM cards, such as VLSIM—very large SIM—offer bigger capacity than regular cell phones), and because the cellular phone may have specific messaging features (which may be proprietary) not supported by every SIM card. A second example of portability problem is observed when there's a need for transferring messages of one first type from one communication device to another communication device having no messaging client for that first type of message. This task is often manufacturer dependent, and usually requires a lot of manual operations. For example a feature for transferring all SMS messages stored in a cellular phone into the e-mail client of a personal computer is not available as far as we know. A third example of portability problem can occur within a single communication device equipped with multiple messaging clients, when there is a need for transferring certain messages from one messaging client to another messaging client (e.g. in order to display all messages stored in a given communication device from a single messaging client instead of having to read each type of message from a different messaging client). A fourth example of portability problem is observed when there's a need to transfer messages of a given type from a communication device having a first type of messaging client for that type of message to a communication device having a second type of messaging client for that same type of messages (e.g. transfer of archived emails from an email client developed by one company to an email client developed by another company). A fifth example of portability problem is the situation, similar to the fourth example above, in which there's a single communication device, equipped with two types of messaging clients for the same type of messages (e.g. Netscape mail and Outlook Express), and messages are transferred from one client to the other inside the same communication device.
A second problem with state-of-the-art communication devices equipped with a messaging client is the problem of synchronization between messaging clients (“synchronization problem”). Synchronizing two messaging clients consists primarily in making sure that every message in one messaging client and meant to be synchronized appears in the other client too. This can be useful for example when a person uses different communication devices (e.g. a PDA or laptop when traveling and a desktop Personal Computer when in the office) and needs to have access to all messages at any time, whether through one or the other device. Synchronization can occur as soon as an event is detected (e.g. whenever a new message is received, sent, deleted etc.), but it is also possible to decide that only certain events (e.g. certain types of messages) will trigger synchronization. It is possible to decide that every personal message (marked as “event to be synchronized” by methods known in state of the art such as flags) will be synchronized, but that other messages will not be synchronized. This however requires configuration by the user. Personal messages can for example be defined as messages originating from or sent to recipients belonging to a list of personal contacts defined in the messaging client. This also needs to be configured by the user. Synchronization can be performed in one way only or in both directions (a messaging client of a communication device 1 can be synchronized with a messaging client of a communication device 2 and vice versa). Synchronization can be performed continuously (whenever a relevant event is detected) or only from time to time. The latter situation can be triggered automatically on a periodic basis (e.g. every week, or every 100 messages received, etc.), or upon user request, or automatically upon detection of certain events (such as detection of high probability of hard disk failure by techniques known in the art such as S.M.A.R.T, Self-Monitoring, Analysis and Reporting Technology, an open standard for developing disk drives and software systems that automatically monitor a disk drive's health and report potential problems), etc. Obviously, this is again a parameter of the synchronization process, which needs to be defined by the user. More than two messaging clients can be synchronized. Such messaging clients may reside on different communication devices. Many tools and standardization bodies (such as OMA) have been put in place in order to facilitate synchronization, but synchronizing messaging clients is still inconvenient in particular for the reasons mentioned above (many configuration steps, not easy for non technicians, and many different tools with different interfaces).
A third problem with state-of-the-art communication devices equipped with a messaging user interface is the fact that messaging user interfaces are often device dependent, i.e. they are developed for that specific device and a device designed by a different manufacturer (and sometimes even a different device designed by the same manufacturer) may have a radically different messaging user interface. We'll refer to that third problem as “the messaging user interface problem”. When a user acquires a different device, the user has to learn how to use a new messaging user interface, while it would have been more convenient to keep a similar user interface for all communication devices.
A fourth problem with state-of-the-art communication devices equipped with a messaging client is the “operator messaging services problem”. Communication devices are under the control of the persons who own them, rather than under the control of the operators of the networks to which such communication devices are connected. For example, in the field of cellular telephony, only the SIM card is the property of the operator whereas the handset belongs to the user or to a third party. As a consequence, it is difficult and sometimes not possible for an operator to manage data stored in the handset without asking the user permission for each action (in particular when such data is stored in a secure repository, which does no grant access without user authorization, and which is not designed to grant access to the operator through the network). Even in situations where such access is made possible, most often there is no tool or protocol letting the network operator know whether the user has accepted the handset operation or not. Therefore performing tasks such as operator services is not easily performed in a transparent way, even if the user wishes to benefit from those tasks. For example, despite his subscription to an operator service, the user might have to accept any access of the operator to its personal data (messages), which might happen very often and therefore be a nuisance for the user. Sometimes such access is not even possible. Examples of operator services to which a user could be willing to subscribe include backup services in which the operator keeps a copy of the user's messages (SMS, MMS, EMS, etc.) on a server, in case the cellular phone is lost, stolen, or damaged.
A fifth problem is the problem of “messages security”. As communication devices are not necessarily specific to one user but may be exchanged or shared between users, all the messages may become readable by anybody having access to the communication device, which raises the issue of security, in particular confidentiality. In general, messages stored in cellular phones are not by default protected by any pin code, encryption or signature mechanism. Although techniques to ensure the confidentiality of messages that are stored in the device (such as those mentioned above) could be devised, they are not usually implemented or activated and would require manual actions to install an application and configure it. Considering that many users use only the most basic features of their communication devices and do not plan to learn how to perform complex tasks that would enable better protection, and are not necessarily informed of the fact that their messages are not protected, we face a security problem.
A sixth problem is the problem of “message availability”. Some communication devices rely on a messaging client located on a server. Alternatively, such communication devices may simply store messages on that server which then acts as a message repository. According to the invention, this sort of implementation, while partially addressing certain aspects of the aforementioned problems, turns out not to be completely satisfactory. Messages can only be read when the communication device is connected to the network. Therefore messages are not accessible when the network is down or when the communication device in offline for any reason. In addition, when the access to the network is not charged on a fixed price basis but with respect to the actual use of the network (e.g. connection duration or quantity of data transmitted), the user needs to pay each time a message is accessed, which results in a lower accessibility of the messages. In addition, access to the messages may be constrained by the bandwidth available. For example, if the network is slow, it is very inconvenient to read the messages. It is even more inconvenient to perform operations involving numerous messages such as search operations. For example if one wishes to find a particular message while only remembering that the message contains a certain keyword, one might have to load all messages through the network and filter them in the communication device, or alternatively one must have access to a software located on the server, such software executing this filtering on his behalf.